The present invention relates in general to the multicasting of computer network datagrams to a plurality of recipients, and, more specifically, to monitoring multicast traffic and providing a means for a network domain that performs replication and transport of multicast datagrams to be compensated by the network domain or service that initiates the multicast traffic.
Packets or datagrams transported over a computer network can be sent as unicast, broadcast, or multicast messages. In the IP protocol, multicast messages use reserved IP addresses (Class D) set aside for multicast groups. For example, a source server or host may distribute streaming multimedia (e.g., video and/or audio) or other information as datagrams specifying a particular multicast group number in the destination address. The datagrams propagate via multicast-enabled routers which typically maintain local group databases identifying next-hop routers and/or end user destinations that have requested receiving datagrams from the multicast group. If a router's database identifies more than one destination for a multicast group, the router replicates the datagram and sends it to each destination.
The IP protocol suite includes the Internet Group Management Protocol (IGMP) for managing the interaction between destinations (e.g., end user clients) and multicast-enabled routers. So that multicast traffic does not have to be sent to clients or routers not interested in the particular traffic, multicast group databases maintained in the routers are constantly updated to identify clients or other routers that should receive traffic belonging to specific multicast groups. In most implementations, a client must send a join request to its neighboring router(s) in order to receive multicast group messages. When a client is no longer interested in a multicast stream, it sends a “leave” message to exit the multicast group.
When a router receives a join message for a multicast group that it is not currently receiving, then the router uses a multicast routing protocol such as Protocol-Independent Multicast (PIM) to create the necessary links from a source of the multicast stream to itself. When no longer needed, the router eliminates or prunes multicast distribution links to it that are no longer needed.
For certain kinds of traffic, multicasting can result in significantly more efficient use of overall network resources since multiple copies of the same information packets between any sender/receiver pair are avoided. The greatest savings are realized by the originating server of the multicast content since it does not have to originate separate traffic streams to each destination. Lesser saving are realized by the network backbone and there may be little or no savings in overhead for the destination network (e.g., an Internet service provider (ISP) operating a local area network (LAN) of a destination client).
In the current business model, the backbone provider and the ISP or other destination network have little motivation to provide multicast-enabled networks. The backbone provider receives compensation from the content provider based on the capacity of the purchased access. Since any particular content received as multicast traffic is no different than the same content obtained using unicast transmission (i.e., multicast content is not distinguishable from unicast content from the perspective of the destination client), there is no obvious improvement gained by an ISP's investment in multicast-enabled networks. Thus, an ISP is unlikely to be able to increase prices charged to end users for being multicast-enabled.
The extra costs of terminating multicast streams at the destination end of the network multicasts are borne by entities that derive the least benefit from the reduced network traffic realizable with multicasting. Since the deployment of widespread multicasting requires broad support from backbone providers and destination network providers, the current Internet business model has failed to motivate adoption of multicasting technologies.